|
|
|
|
|
|
|
probably be a variant. No matter how you look at it, the results are unlikely to be what you intended. The extra effort involved in declaring each variable before you use it is nothing compared to the pain and suffering of finding obscure bugs caused by typographical errors. |
|
|
|
|
|
|
|
|
VII
Honor thy VB integers and thy Win32 integers, for they are not alike. |
|
|
|
|
|
|
|
|
An integer is 16 bits. Or is it? Under Win32, if you are reading C or C++ documentation (which is the default language for all Windows documentation), an "int" and all references to integers actually refer to a 32-bit value. So, if a person or document refers to "integers," it is essential that you keep in mind the context of the reference. |
|
|
|
|
|
|
|
|
VIII
Always recheck thy function names, for they are now case-sensitive and may have suffixes. |
|
|
|
|
|
|
|
|
All API function names are case-sensitive under Win32. This differs from the Win 16 API, where the case of function names did not matter. Also watch out for suffixes in situations where the function takes string parameters. There is a good chance that the actual name of the function in the DLL has the letter "A" or "W" as a suffix, indicating the ANSI or Unicode entry point for the function. |
|
|
|
|
|
|
|
|
IX
Thou shalt check parameter and return values. |
|
|
|
|
|
|
|
|
One of the nicest things about Visual Basic is that it is an interpreted language. This means you can stop your code at any point in the execution and examine the values of each parameter. If an API call is not working as you would expect, stop at that point and examine the actual parameter values being used in the call. Look for values that make no sense, especially parameters that should contain valid data but contain 0 instead (suggesting a failure in a previous API call). Check the return values of the functions and use the Err.LastDllError method call to obtain additional information about the failure. |
|
|
|
|
|
|
|
|
The nice thing about using API function calls is that, once you have them declared and coded correctly, they are extremely reliable. The not-quite-as-nice thing about using API functions is that, until you have them declared and coded correctly, your errors are likely to lead to memory exceptions that crash your program, freeze Visual Basic, and on occasion even crash your system. There is nothing quite like the frustration of hitting the Run button after adding dozens of lines of new code, only to have the code vanish in a memory exception. For peace of mind, I personally save my work every time I run my code. It's an approach I strongly recommend. |
|
|
|
|
|